Conventionally, connecting multiple communications apparatuses, each having its own communications function, via a network for communicating, and building various systems are performed. As an example, there is a so-called electronic-commerce system such that an order for a product is transmitted from a computer such as a PC (Personal Computer) that functions as a client apparatus and accepts the order in a server apparatus that communicates with the client apparatus via the Internet. Moreover, a system is being proposed such that various electronic apparatuses are provided with a function of a client apparatus or a server apparatus so as to be connected via an network, and are remotely controlled by mutual communications.
In building such systems, it is important to confirm when communicating whether a communications counterpart is appropriate, or whether information being transmitted has not been tampered with. Moreover, especially in the Internet, as often information goes through computers that are unrelated before reaching the communications counterpart, when transmitting secret information, there is also a demand for making sure that the contents are not viewed secretly. Then, a protocol such as SSL (Secure Sockets Layer), for example, as a communications protocol to respond to such demand is being developed and widely used. Using this protocol to communicate combines public-key encrypting methods and common-key encrypting methods for authenticating the communications counterpart as well as preventing tampering and tapping by encrypting information. Moreover, even at the communications-counterpart side, a communications-originating apparatus that requests for communications is authenticated.
As technologies related to authentication using such SSL and public-key encrypting, there are those described in Patent Documents 1 and 2:
Patent Document 1
JP2002-353959A
Patent Document 2
JP2002-251492A
Now, a communications procedure for mutually authenticating according to this SSL is described focusing on the authentication process portion. FIG. 27 is a diagram illustrating a flow of a process of executing in each apparatus when communications apparatuses A and B mutually authenticate according to the SSL, along with information used for the process.
As illustrated in FIG. 27, when mutually authenticating according to the SSL, there is a need to first have a root-key certificate, a private key, and a public-key certificate stored in both of the communications apparatuses. This private key is a private key issued to each apparatus by a CA (Certificate Authority), while the public-key certificate is one such that the public key corresponding to the private key is appended with a digital signature by the CA so as to be set as a digital certificate. Moreover, the root-key certificate is one such that a root key corresponding to a root-private key used in the digital signature is appended with a digital signature so as to be set as a digital certificate.
FIGS. 28A and 28B illustrate these relationships.
As illustrated in FIG. 28A, a public key A is configured from a main body of the key for decrypting text encrypted using a private key A, and bibliographical information which includes such information as issuer (CA) of the public key and validity. Then, in order to indicate that the main body of the key and the bibliographical information are not tampered with, a hash value obtained by hashing the public key A is encrypted using a root-private key so as to be applied to a client common key as a digital signature. Moreover, at that time, information identifying the root-private key used in the digital signature is added as signature-key information to the bibliographical information of the public key A. Then, the public-key certificate having this digital signature applied is a common-key certificate A.
When using this common-key certificate A for authenticating, the digital signature contained therein is decrypted using a main body of a root key being a public key corresponding to the root-private key. It is understood when this decrypting is performed successfully that the digital signature is certainly applied by the CA. Moreover, it is understood when the hash value obtained by hashing the public key A portion and a hash value obtained by decrypting matches that the key itself is also neither damaged nor tampered with. Furthermore, it is understood when it is possible to successfully decrypt the received data using this public key A that the data is transmitted from the owner of the private key A.
Now, while it is necessary to store in advance a root key for performing authentication, as illustrated in FIG. 28B, this root key is stored as a root-key certificate having applied a digital signature by the CA. This root-key certificate is in a self-signature format enabled to decrypt the digital signature with a public key contained therein. Then, when using the root key, the main body of the key contained in the root-key certificate is used to decrypt the digital signature so as to compare with the hash value obtained by hashing the root key. When there is a match, it is possible to confirm that the root key is not corrupted, for instance.
Now the flowcharts in FIG. 27 are described. It is noted that in this diagram, an arrow between the two flow charts represents transferring of data such that the transmitting side performs a transferring process at a step from which the arrow originates, while the receiving side once the information is received performs a process of a step to which the arrow points. Moreover, when a process of each of the steps is not successfully completed, at that time a response of having failed authentication is returned so as to suspend the process. The same holds when a response of having failed authentication is received from the counterpart, or upon time-out of the process.
Now, with a communications apparatus A requesting for communications with a communications apparatus B, when performing this request, the CPU of the communications apparatus A executing a required control program starts a process of the flowchart illustrated on the left-hand side of FIG. 27. Then, in step S11, a request for connection is transmitted to the communications apparatus B.
On the other hand, the CPU of the communications apparatus B once receiving this request for connection executing a required control program starts a process of the flowchart illustrated on the right-hand side of FIG. 27. Then, in step S21 a first random number is generated for encrypting using a private key B. Then, in step S22, the encrypted first random number and a public-key certificate B are transmitted to the communications apparatus A.
At the communications apparatus A side, when receiving this, in step S12 the validity of the public-key certificate B is confirmed using a root-key certificate.
Then once confirmed, in step S13 the first random number is decrypted using a public key B contained in the received public-key certificate B. When the decrypting here is successful, confirming that the first random number is certainly received from a subject to which the public-key certificate is issued is enabled. Then, when the confirming as described above is enabled, information indicating success of authentication is transmitted to the communications apparatus B.
Moreover, at the communications apparatus B side, upon receiving this information, in step S23, transmission of a public-key certificate for authentication is requested to the communications apparatus A.
Then, at the communications apparatus A, based on the above request for transmission, in step S14, a second random number and a common-key seed are generated. A common-key seed may be generated based on data transacted in previous communications, for example. Then, in step S15 the second random number is encrypted using a private key A, the common-key seed is encrypted using the public key B, and in step S16 these are transmitted with a public-key certificate A to the server apparatus. Encrypting the common-key seed is performed for the purpose of making sure that the common-key seed is not known to apparatuses other than the communications counterpart.
Then, in the next step S17, a common key for use in encrypting subsequent communications is generated from the common-key seed generated in step S14.
At the communications apparatus B side, when receiving this, in step S24 the validity of the public-key certificate A is confirmed using the root-key certificate. Then once confirmed, in step S25, the second random number is decrypted using a public key A contained in the public-key certificate A received. When the decrypting here is successful, confirming that the second random number is certainly received from a subject to which the public-key certificate A is issued is enabled.
Subsequently, in step S26 the common-key seed is decrypted using a private key B. It can be said that, in the process thus far, the common-key seed common to the communications apparatus A side and the communications apparatus B side are shared. Then, the common-key seed does not become known to apparatuses other than the communications apparatus A having generated the seed and the communications apparatus B having the private key B. Once the process described thus far succeeds, also at the communications apparatus B side in step S27 a common key for use in encrypting subsequent communications is generated from the common-key seed obtained by decrypting.
Then, once the process of step S17 at the communications apparatus A side and the process of step S27 at the communications apparatus B side are terminated, success of authentication and encrypting method for use in subsequent communications are mutually confirmed for terminating the process regarding authentication assuming that the generated common key is used to conduct the subsequent communications using the encrypting method confirmed as described above. It is noted that the confirming as described above includes a response from the communications apparatus B that authentication has succeeded. The process as described above enables mutually establishing communications so as to subsequently use the common key generated in step S17 or S27 and to encrypt data according to the common-key encrypting method for conducting communications.
Performing such process as described above enables securely sharing a common key upon the communications apparatus A and communications apparatus B mutually authenticating their counterparts, and establishing a path for communicating securely.
It is noted that in the process as described above, it is not mandatory to encrypt the second random number with the private key A and to transmit the public-key certificate A to the communications apparatus B. In this way, while it is not possible for the communications apparatus B to authenticate the communications apparatus A, this process is sufficient when it suffices for the communications apparatus A to only authenticate the communications apparatus B. Then in this case, it is necessary to have only the root-key certificate stored in the communications apparatus A so that neither the private key A nor the public-key certificate A are needed. Moreover, it is not necessary to have the root-key certificate stored in the communications apparatus B.
Now, when using such authentication process for identifying a subject for providing a service such as remote control, a certificate, etc., required for authentication process is to be stored in a subject apparatus for providing the service (an apparatus at the user side). Then, an apparatus providing the service, based on information provided in the certificate, etc., determining whether a communications counterpart is an apparatus suitable as a subject for providing the service is performed. Moreover, if the information provided in the certificate, etc. is not sufficient, obtaining an equipment-number information for use in the determining as described above, after establishing a communications path, is performed.
Moreover, a certain apparatus being a subject for providing the service for a predetermined period may no longer be a subject for providing the service upon dissolving an agreement. In such a case, nullifying a certificate of the apparatus which is no longer a subject for providing the service is required.
As a technologies related to such nullifying, technologies as described in Patent Documents 3 and 4 are known.
Then, in the Patent Document 3, a technology is described in which an Issuing Authority (IA) for providing an authentication service such as a public-key registration based on a request from a Registration Authority (RA), upon receiving from the RA as described above a request for nullifying a public-key certificate of the RA itself, retrieves a public-key certificate of an user that is registered from the RA so as to nullify the public-key certificate of the user. Moreover, in Patent Document 4, a technology is described in which a pubic-key authentication apparatus analyzes a request for nullifying a public-key certificate that is received from an attribute-authentication apparatus to extract a public-key certificate to be nullified so as to nullify the extracted public-key certificate in a database.
Patent Document 3
JP2002-247028A
Patent Document 4
JP2002-058049A
However, with the techniques as described in these Patent Documents 3 and 4, nullifying of the public-key certificate of the user is provided for performing only at the side managing the certificate, or the side providing the service. In other words, a process of deleting user information and certificate identification number regarding the public-key certificate for nullifying is provided for so that while the fact that the public-key certificate is nullified is communicated to the user, no action is performed on the public-key certificate, etc. which has been stored in the apparatus at the user side so as to leave the public-key certificate, etc. as it is.
Therefore, in the apparatus at the user side, the common-key certificate at the time of being provided the service remains to be stored. Therefore, there was a problem such that there is the potential that a certificate or a key may leak out, get copied, or be abused. Such item as the certificate is being set up as a nullified one at the service provider side. However, it is not preferable for these items to leak out unlimitedly as the certificate itself is within its validity period and is no different from a valid certificate or key from in terms of the respective forms unless there are particular circumstances such as having dissolved an agreement in tandem with expiration of the validity period.
Moreover, there was a problem such that as the apparatus at the user side is still in a state of being able to attempt accessing an apparatus at the service providing side, a process load arises with the apparatus at the service providing side to determine that this access is out of scope of providing the service so as to reject communicating. This kind of process load becomes greater when the user-side apparatus has a function of automatically accessing the service providing side once every certain time period. As a method of reducing this process load, while a CRL (a Certificate Revocation List) may be registered so as to make impossible communications according to the SSL with the out-of-scope apparatus, even such method does not completely eliminate the process load as, long as there is an access.
Then, as it is not desirable to spare processing power for dealing with apparatuses which are out of scope for providing the service, there was a demand for reducing such process load as much as possible.